1. Field of the Invention
The present invention relates to communication systems and, in a particular implementation and aspect, to methods and systems for testing the reliability of software.
2. Description of Related Art
Mobile communication networks, such as GSM (Global System for Mobile communications) networks, have recently become extremely widespread and popular. Additional services that are connected with and accessed via these mobile networks, and in fields that are quite varied and versatile, have correspondingly increased at an accelerated pace. For example, a mobile telephone may be used as a means of payment for minor purchases, as for soft drinks and automated car washes. Everyday activities, such as payment transactions, banking services, etc., have also been added, and will continue to be added, to the functionality of and which is provided by and through current mobile phones. Next generation mobile stations will be even more advanced in respect of the realizable level of service and data transfer capacities as compared with current and prior mobile stations.
With the aid of digital signing, which is widely recognized to be a general requirement for commercial implementations of electronic payment, it is possible to insure the coherency of the information to be sent and the identity of the source address. A digital signature is derived by encrypting a checksum which has been computed using the information to be sent with a sender's private key. Since only the sender knows the corresponding private key, when the encrypted information is decoded using the sender's public key the recipient can readily confirm that the information sent has not been modified and that it has been generated using the genuine private key which is known only to the sender. One example of an algorithm commonly used in digital signing is the RSA ciphering algorithm, which is based on an encryption system using the public and private keys of an individual or party and which is also used for the encryption of messages.
In the public key infrastructure a user maintains secrecy and control over that user's private key, but makes the corresponding public key freely available to all others. It is nevertheless not enough to simply store the public key in an accessible location, such as in an electronic mail directory or public database, because a third party could modify or forge the stored public key to make the forger the apparent authentic owner of the key. Instead, certification and security certificates are used to serve as proof given by a trusted party (the certification authority) of the fact that the name, identification number and public key belong to the same person. The certificate is typically a combination consisting of a public key, a name and identification number, etc, which the certification authority has then signed with the private key of the certification authority.
When the recipient of a digitally signed message wishes to confirm the authenticity of the message, that recipient must first obtain the digital certificate, which will provide the recipient with the public key and the name of the sender of the message. The recipient must then authenticate the certificate, which requires him or her to obtain additional certificates (i.e. a certification chain) for use in authenticating the subject certificate.
Where the certificate is thereby determined to be authentic, the recipient can authenticate the signature of the received message by using the public key that accompanied the certificate. If the signature passes the test, then the sender has been confirmed to be the person identified by the certificate. In certification arrangements, a special block list is used to list certificates that have been taken out of use; thus, directory services are needed to support and enable access to both the certificates and the block list.
The design and construction of mobile phones utilize at least partly embedded systems and software. These implementations permit at least partial modification of the original software and of the functionality provided by the mobile phone, thereby permitting the phone to be updated by the mobile provider. However, this same capability for intended modification likewise permits modification for improper purposes. Thus, by suitably modifying the software the content of electronic payment messages may be changed for the specific purpose of defrauding the user or service provider in carrying out a transaction, such as by changing account numbers, sums subject to transfer or payment, digital signatures, etc., even though the user may view or be provided with the correct information about the transaction on a display screen of the mobile phone.
It is at the present time impossible for the user to check or determine whether the mobile phone that he is using contains or is operating with the original (or otherwise legitimately modified) software of the manufacturer or, alternatively, if the software has been otherwise modified. Where the mobile phone is utilized for carrying out banking services, such as for payments or transfers of funds, the user must have the ability to verify that the device is using the valid, original, authorized version of the relevant software.
What is most important to the user is the ability to determine or verify the reliability of the display and keyboard, the presence of security, the security and reliability of the communication channels used by the mobile device, and the originality or authenticity of the components or software associated with the provision of security, such as secure storage of subscriber identification data, passwords and key codes. In addition, the user must be able to check the software at random and unpredictable times at which the software is not otherwise prepared or expecting to be checked.
In principle, software may be checked or validated by way of so-called direct checking in which two independent checksums are computed on the mobile phone software, as for example using an effective hash function such as SHA-1 or MD5 or the like, and are then compared. The first checksum is computed on the software stored on the mobile phone itself and the second is computed by the manufacturer or supplier of the original software. The first and second checksums are then compared and, if they match, the software of the mobile phone is deemed to be original and authentic. However, the problem associated with this known solution is the fact that modified or forged software may itself be programmed to ignore the results of the comparison, and instead print or report only the original checksum as if it were the newly computed checksum that was requested by the user.